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FIELD OF THE INVENTION 

The present invention relates to communication services, and in 
particular to delivery of messages to selected recipients through one or more 
specified communication modes. 


I 10 BACKGROUND OF THE INVENTION 

o 

ru Thanks to improvements in technology and widespread consumer 

S interest, once-exotic forms of communication have become commonplace, 

and today the average consumer has access to a broad array of 
communications services. The Internet and wireless telephony, once the 
1 5 preserve of an elite few, now routinely supplement traditional telephone 

services and are frequently supplied by the same carriers. Even inexpensive 
home computers now include facsimile capability. Businesses employing 
mobile employees can furnish them with economical pagers that incorporate 
advanced features, such as text transmission and Internet access. 
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The sheer proliferation of communication options, while greatly 
improving access and convenience, has engendered problems as well. The 
existence of a communication channel does not ensure that the recipient of a 
message will be "listening" to that particular channel at a given time, yet the 
5 sender of a message has no way to know this. Indeed, more channels of 
communication traffic mean more demands on the attentions of potential 
recipients, who, feeling besieged by the assault of e-mail, voice mail, pages, 
etc., may simply inactivate some communication devices at different times. 
Message senders, therefore, are faced with the choice of risking non-delivery 

^ 1 0 of their messages, or painstakingly re-transmitting a message on every 

J possible mode of communication modality. 

q It may also be difficult to transmit the same message to multiple 

3 recipients. While a single e-mail message, sent once, can reach an unlimited 

y number of destinations, phone messages must be repeated for each call. 

S 1 5 Moreover, different recipients may have access to different types of 

communication channels; perhaps some recipients can be reached efficiently 

only by e-mail, others by fax, and still others by page. 

The integration of communication input devices also raises the 
prospect of messages having multiple forms of content. Today, a single 
20 message may include input from a variety of sources (e.g., voice and text); 
transmitting such a message by traditional means may be quite cumbersome, 
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involving multiple separate transmissions that must be coordinated or difficult 
"packaging" of the different inputs into a single message. 

U.S. Serial No. 09/496,170, filed on February 1, 2000 and entitled 
Multi-Mode Message Routing and Management (the entire disclosure of 
5 which is hereby incorporated by reference) addresses these difficulties and 
discloses, inter alia, a facility for transmission of messages composed on one 
or more input devices to a single or multiple recipients by means of one or 
plural communication modalities. Such communication modalities may 
include, for example, conventional or wireless telephone, facsimile 

10 transmission, pager, e-mail, postal mail or courier. Thus, a message may be 
directed to a single recipient via multiple modalities, such as e-mail and fax, 
in order to ensure the earliest possible receipt of the message; or may be 
directed to multiple recipients by a single modality or by different modalities 
(e.g., some recipients receive the message by e-mail, others by fax, others 

15 by phone). The facility may be configured to respond to defined "escalation" 
rules that specify conditions under which different delivery modalities may be 
sequentially employed. For example, the rules may specify that if there is no 
response to an e-mailed question within an hour, the recipient is to be 
telephoned. Moreover, in addition to alternative transmission modalities, the 

20 escalation rules may specify alternative recipients (as well as alternative 

modalities for those recipients). The escalation rules may also specify default 
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contact methods, which may apply to specific individuals or to lists of 
recipients. 

The invention disclosed in the '170 application may include 
functionality for determining whether a message has been received (e.g., 
5 telephone and e-mail polling), as well as automatic sender notification upon 
confirmation of receipt. Moreover, in addition to monitoring messages in 
order to confirm their receipt, the invention may facilitate recipients' 
responses. In this way, the invention can orchestrate multi-question surveys 
utilizing multiple communication modes; for example, individuals contacted 
10 directly can respond immediately, while others can respond later in 

accordance with instructions delivered to them— e.g., via a web site or by 
calling a toll-free number. 

The invention disclosed in the '170 application supports messages 
having embedded questions that call for response by the recipient. Such 
1 5 responses, when received, may be communicated to the message sender 
and/or accumulated. 

Also facilitated by the invention disclosed in the '170 is scheduling of 
message delivery, on a mode-by-mode basis where appropriate. Scheduling 
may include delivery at a particular time or within a designated time window, 
20 or may involve preventing delivery during specified "black-out" periods. In 
some embodiments, scheduling may be automatic and based on 
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considerations such as the recipient's time zone and the form of 
communication (e.g., to avoid awakening the recipient by telephone). 

However, the '170 application contemplates a system in which 
customers' client computers communicate via the World Wide Web (the 
5 "web") with a server implementing the foregoing functions. In other words, 
the interaction is essentially manual and stepwise in nature, with customers 
selecting options and indicating preferences in an interactive session. This 
model is generally unsuited to business applications requiring more 
□ automated, high-volume access to messaging functions. 

ru 10 

1 DESCRIPTION OF THE INVENTION 

2i Brief Summary of the Invention 

g The present invention provides an application program interface (API) 

facilitating interaction, generally (although not necessarily) via the Internet, 
1 5 with a message-handling facility such as that disclosed in the '170 

application. In accordance with the invention, application programmers 
utilize a markup language (preferably XML-derived) to configure applications 
for compatibility and communication with the message-handling facility. The 
API is capable of processing high-volume requests for message routing, 
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status information, and various other functions on an automated basis, 
enabling businesses to make routine use of these functions. 

Indeed, the range of business-to-business and business-to-consumer 
organizations that can benefit from flexible messaging services is virtually 
5 limitless. For example, an airline may obtain contact information from 
passengers when tickets are purchased. Should a flight be delayed or 
cancelled, the airline can generate a single notification for transmission to all 
passengers via the messaging facility; as the flight time approaches, efforts 
to reach passengers not yet contacted can be intensified according to defined 

10 escalation rules. Similarly, a club or other organization can send out notices 
of meetings, receive confirmations and preferences from members, and alert 
them to changes using the messaging facility by means of the API. The 
message need be written and transmitted by the organization only once; all 
remaining operations, from bulk re-transmission to collecting and organizing 

1 5 responses, are performed automatically. 

In accordance with the invention, a message server comprising a 
plurality of modalities for transmitting messages is associated with an API. 
An application, typically implemented on a remote server, is configured to 
receive a message and a designation of one or more transmission modalities, 
20 and is further adapted for interaction with the API. The API comprises stored 
instructions supporting the interaction. Upon receiving the message and the 
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designation from the application server, the API causes the message server 
to transmit the message according to the designation. 

Brief Description of the Drawings 

The foregoing discussion will be understood more readily from the 
following detailed description of the invention, when taken in conjunction 
with the accompanying drawings, in which: 

FIG. 1 schematically represents the environment of the invention; and 

FIG. 2 schematically illustrates the components of the API and its 
mode of interaction- 
Detailed Description of the Preferred Embodiments 

7. Technical Context 

The functions of the messaging system are implemented by a server 
125, which may be realized as a single workstation or as a network of server 
computers, depending on the activity level and included functionality. For 
explanatory purposes, server 1 25 is represented as a single machine that 
includes a network interface 1 27 continuously connected to the Internet. 
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Network interface 1 27 and the other internal components of server 1 25 
intercommunicate over a main bidirectional bus 1 30 (which may be a 
physical bus in a single hardware device, or can instead represent a network 
such as a LAN or a WAN). The main sequence of instructions effectuating 
5 the functions of server 125 and facilitating interaction among customers, 
server 1 25, the Internet, and other modes of communication reside on a 
mass storage device (such as a hard disk or optical storage unit) 1 32 as well 
as in a main system memory 134 during operation. Execution of these 
instructions and effectuation of the functions of server 1 25 is accomplished 
10 by a central-processing unit ("CPU") 136. 

A group of functional modules that control the operation of CPU 1 36 
and perform the operations of server 1 25 is shown conceptually as located in 
system memory 1 34; once again, however, it should be stressed that this 
organization is for explanatory purposes. The various modules and servers 
1 5 may indeed be implemented as active processes running on a single machine, 
but functionality may instead be distributed among multiple machines (or 
processors within a single machine), once again depending on the activity 
level and included capabilities. 

An operating system 140 directs the execution of low-level, basic 
20 system functions such as memory allocation, file management, and operation 
of mass storage devices 132. At a higher level, a control block 142, 
implemented as a series of stored instructions, manages interaction among 
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the various functional components of the server and ensures proper routing 
of data thereamong. 

Although server 1 25 may be capable of communicating directly with 
customers by means of the web and electronic mail, as explained in the '170 
application, the present application is concerned primarily with hardware-to- 
hardware communications. Accordingly, an API 145 receives and processes 
communications from external sources, and transmits proper responses to 
those sources, via network interface 127. API 145 represents a 
programmatic interface for direct connection to appropriately configured 
third-party applications. The pattern of interaction with the external source, 
including the content of transmissions thereto, is handled by a transaction 
server 1 50. Transaction server 1 50 has access to various databases, 
collectively indicated at 1 52; these databases, discussed in greater detail 
below, are ordinarily stored on devices 132 and accessed as necessary. 
Depending on the requests received by API 145, transaction server 150 
causes messages to be assembled and transmitted to designated contacts, 
and retrieves and assembles information for transmission to outside inquiries. 
Credit-card validation and billing for services are handled by a billing server 
160. 

The various functions performed by server 1 25, which result in 
different patterns of interaction with customers, will now be described. 
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7. 7 Media Conversion and Basic Message Transmission 

A series of media servers, collectively indicated at 175, represent the 
interface servers that format messages for transmission; these messages 
may be in the form of voice, text (for transmission by e-mail, web or postal 
5 mail), or other desired format. Messages and media designations are 

received from remote applications via API 145, and once transaction server 
1 50 has received sufficient commands and content to fully specify a 
message (i.e., the message body, the recipient(s), desired delivery methods, 
and message options such as delivery scheduling and/or escalation rules), a 
10 message "job" is created and stored in a database 1 52. The job is passed to 
a job queue server 165, which is responsible for implementing and 
scheduling all message jobs. 

At this point, the message remains in the format in which it was 
generated. As noted previously, however, server 125 is capable of receiving 

1 5 messages, via the interface servers, in one format and transmitting them in a 
different, customer-selected format. The functions of media conversion and 
message assembly are performed by a series of message delivery servers, 
collectively illustrated at 1 67, dedicated thereto. The appropriate message 
delivery server 1 67 converts messages to the specified format and causes 

20 their transmission, via the designated communication medium, by means of a 
corresponding device driver selected from among a suite of drivers. The 
drivers operate a series of transmission devices, which include network 
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interface 1 27 for e-mail and/or web-based message delivery; a telephone 
interface 170 for message transmission by telephone, facsimile, pager, or 
handheld wireless device (although it should be noted that pager and wireless 
transmission can occur through network interface 127); and a document- 
5 generation module 1 72 for message transmission by postal mail or overnight 
courier. 

The timing of message transmission is governed by job queue server 
1 65. In response to the customer's authorization to send a message, job 
queue server 1 65 triggers the conversion and transmission operations just 
10 discussed. Job queue server 165 also contains (or, as shown for illustrative 
purposes, communicates with) a scheduling module 180, which can 
orchestrate transmission of messages at customer-specified times based on 
the computer's internal clock. 

Server block 1 65 may contain a text-to-speech conversion module, 
1 5 enabling customer-provided text to be transmitted by voice to the recipient 
by means of telephone interface 1 70. Conversely, telephony server 1 75 may 
be configured to respond to spoken customer commands, allowing the 
customer to compose and address a message by telephone (i.e., by 
communicating with server 125 by means of telephone interface 170). 

20 In still more complex operational modes, server 1 25 may facilitate 

catenation of message— either as separate segments of the same format, or 
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as segments encoded in different formats. In the case of audio messages, 
for example, a message delivery server 167 may append an audio "header" 
(typically a so-called "professional prompt") and a "trailer" to the customer's 
message. Thus, when the recipient answers the telephone, the header 
5 portion of the message may tell him that he is about to receive a message 
from the customer, and the trailer portion may facilitate response (as 
explained in further detail below). 

7.2 Confirming Message Receipt 

Any of a variety of techniques can be used to assess whether and 
10 when a message is received. Many e-mail systems natively support receipt 
confirmation. Alternatively, a URL can be embedded in the message; when 
the recipient receives the e-mail and clicks on this URL, receipt is 
automatically recorded. Moreover, the URL-specified web page may contain 
questions inviting response by the recipient, who thereupon transmits the 
1 5 web page back to server 1 25. 

Hard-copy deliveries can be tracked through the courier or by means of 
a follow-up telephone call to the recipient, while for telephone messages, the 
recipient can be asked to press a number to confirm receipt. In the context 
of telephone messages, it may be useful to detect whether a person or an 
20 answering machine has answered the phone. This determination can be 
used, for example, to select a proper audio header or even to choose 
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between alternative messages, which may differ depending whether the 
message is delivered to the recipient or a recording device; an answering 
machine, obviously, would not be asked to press a number to confirm 
receipt, nor would delivery typically be confirmed to the sender if the 
5 message was left on an answering machine. To implement answer 

detection, telephony server 1 47 is programmed to monitor the level of noise 
on the line once a connection is established, distinguishing between a 
"silence" noise level and a "speech" level. If an individual answers, he or 
she will typically issue a short greeting; that is, the signal pattern of a human 
*? 10 answer is a short speech signal followed by silence. An answering machine, 
by contrast, will generally issue a long greeting ("Hello, you have reached the 
Smiths ..."). Based on the observed lengths of a sustained speech signal 
and an ensuing silence, telephony server 147 forms an initial guess as to 
whether a person or a machine has answered. If a person is guessed, 
1 5 telephony server 1 47 will play the audio header that prompts the answerer to 
press a touch-tone key, and if the proper touch-tone pulse is not detected, 
server 147 may revise its guess and assume that it is communicating with an 
answering machine. 

1.3 Message Scheduling 

20 It may not be appropriate to transmit messages by certain modes 

during particular time periods at the recipient's location. These "blackout" 
time periods may be established automatically by server 125, or may be 
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designated by the customer or the recipient. Via API 145, an external 
application may indicate blackout time periods for a particular message, or 
may permanently designate such periods for particular contacts (and 
particular communication modalities). Most commonly, permanently 
5 designated blackout periods are used to prevent messages from being sent 
by telephone or pager during times when the recipient is generally likely to be 
asleep or away from the communication modality. Message-specific 
blackout periods may be utilized by message senders familiar with the 
recipient's immediate schedule, or who do not wish to permanently establish 
10 blackout periods. 

Conversely, the external source may specify particular allowed time 
windows within which a message must be delivered. Once again, these may 
be established permanently for particular contacts or "on the fly" for specific 
messages. 

1 5 Time-zone scheduling may be employed automatically. For example, if 

the customer authorizes immediate message delivery at a time that would be 
late at night where the recipient is located, or schedules message delivery for 
such a time, transaction server 1 50 may cause the customer to be prompted 
with this information and asked to confirm or reschedule delivery. 

20 
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1.4 Escalation 

Rather than send a message to a prospective recipient redundantly via 
multiple communication modalities, transaction server 1 50 may be 
configured to allow the specification of escalation rules for sequential 
5 transmission as necessary. The external application selects a plurality of 
communication modalities and/or contacts, and criteria in the form of rules 
governing their use. Typically, an escalation rule will specify resort to a 
different communication modality (or a different recipient) if delivery of the 
message is not confirmed by a specified time, or within a specified period, 
10 using the current communication modality. 

Like scheduling restrictions, escalation rules may be defined 
permanently for a contact (and stored, along with "address book" 
information pertaining to that contact, in database 1 52b) or may instead be 
defined for a particular message. Default message modalities and permanent 

1 5 escalation rules are particularly useful in the context of distribution lists, 
since the external application can simply enter a message and leave it to 
server 1 25 to deliver it to every person on a selected distribution list in 
accordance with each contact's escalation rules. On the other hand, 
message-specific escalation rules may be designated for particular messages 

20 transmitted to API 145. 
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To implement the escalation rules, the time period specified in a rule 
relevant to the initial message transmission is sent to scheduler 1 80. At the 
end of that time period following transmission, transaction server 1 50 
determines whether the message has been received in the manner described 
above. If not, the escalation rule (defined in database 1 52b or in the 
transaction record for the particular message) is executed, and the message 
re-transmitted by a different modality. If further escalation rules remain for 
the message, the appropriate time period is once again provided to scheduler 
180, and the flow sequence repeated. 

2. An Exemplary Application Program Interface 

With reference to FIGS. 1 and 2, external sources such as a server 
1 90 generate requests for messaging functions and status information, and 
transmit these to server 1 25 via a computer network, such as the Internet, 
for processing. FIG. 2 illustrates in greater detail the role and basic 
components of API 145. Requests are actually generated by an application 
210 running as an active process on server 190. Application 210 formats 
these requests in the syntax allowed by API 145. Requests received by API 
145 from application 210 are analyzed by a parser 210, which interprets the 
request and causes the various server modules of server 1 25 to take 
appropriate action. The server modules may generate direct responses to the 
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requests or provide status information for transmission to application 210. A 
converter 220 places such information into statements conforming to the API 
syntax prior to transmission. 

Preferably, the API syntax conforms to the conventions of XML, using 
5 "tags" to characterize elements such as statements and field data. A tag 
surrounds the relevant elements), beginning with a string of the form 
<tagname> and ending with </tagname>. Thus, parser 215 can be (or be 
based on) a conventional XML parser. 

The contents of a communication to or from API 145 take the form of 
10 a "document," which contains an identifying tag and either a "Request" (for 
documents generated by application 210) or a "Response" (for documents 
that API 145 returns to applications 210). Document elements are 
hierarchically organized into objects. Each object specifies the contents of 
fields associated with the object, and may also contain one or more nested, 
1 5 hierarchically inferior objects; this structure maintains the organization of 

information, facilitates movement of information in meaningful packages, and 
allows for re-use of information without explicit repetition. 

At the highest hierarchical level, "Super Objects" define the 
communication as a Request or a Response, and contain one or more "Major 
20 Objects." The Major Objects specify key functional elements of messaging 
activities, defining the relevant user accounts and the nature of the desired 
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message functions, and may contain sub-objects and/or entries for various 
fields within the Major Objects. Fields contain information, such as character 
strings or numbers, relevant to the objects containing them. 

The overall organization of a preferred implementation of API 145 
5 appears in summary form below; following the summary, the various objects 
and fields are described in greater detail. It should be understood that this 
API is illustrative only. 


S Table 1 

FU Basic API Organization 


I. Super Objects: contain required fields and one or more major objects 

A. Request (fields:) 

i) UserName 

ii) Password 

iii) Domain 

iv) OEMId 

v) OEMPassword 

vi) RequestType 

B. Response: same fields/objects as request + errors, warnings 

II. Major Objects: required elements of documents, may contain sub- 
objects and fields 

A. Member (fields:) 

i) Command 

ii) Id 

iii) FirstName 
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iv) LastName 

v) Company 

vi) UserName 

vii) Password 

viii) AllowNotices 

ix) Dialinld 

x) Dialin Password 

Member (subobjects:) 

i) Contact Method 

ii) Billing (fields: Id; Billing Plan; CurrentBalance) 

iii) Credit Card (fields you'd expect) 

B. Contact (subobjects:) 

i) Contact Method (fields:) 


a. 

Id 

b. 

Transport 

c. 

Qualifier 

d. 

Ordinal 

e. 

PhoneNum, FaxNum, PagerNum 

f. 

Access Code 

g- 

Email Address 

h. 

Street 1 

i. 

Street2 

j- 

Suite 

k. 

City 

1. 

State 

m. 

Zip 

n. 

Country 

Contact MethodRef (fields:) 

a. 

Id 

b. 

FirstName, LastName, Company 

c. 

Transport, Qualifier, Ordinal 

d. 

AllowMultiple 


Contact (fields:) 

i) Command 

ii) Id 

iii) Prefix (optional) 
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iv) First Name, Middle Name, Last Name 

v) Company (optional) 

vi) Title (optional) 

C. Distribution List (fields:) 

i. Command (create, replace, append, delete, remove) 

ii. Name 

iii. Description 

iv. Id 

D. Job (fields:) 

i. Id 

ii. Charges 

Job (subobjects:) 

i. Message (fields:) 

A. Subject 

B. Template (optional) 

C. Id 

D. Date 

Message (subobjects:) 

A. MessageArg Objects: series of Name/Value tags: 


1) 

SENDER 

2) 

BODY 

3) 

ASK YESNO QUESTION 

4) 

QUESTION TO ASK 

5) 

EMAIL ADDR 


B. DeliveryTime Objects 

C. DeliveryTimeModifier Objects 

ii. Contact (to specify one-time recipient of message) 

iii. Delivery Request (elements:) 

A. DeliveryOptions field (in) 

B. Contact MethodRef sub-object 

Delivery Request (returned elements:) 
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A. ContactMethod 

B. Contact 

C. Delivery (fields:) 

1) Id 

2) Timestamp 

3) Duration 

4) Status (Not Sent, Sent, Failed, Cancelled, 
Cancel Pending) 

5) Details (Bad Address, Delivery Address is 
unreachable, No Answer, Busy, Answering 
Machine (assumed), Answering Machine, 
Maximum Delivery Attempts Exceeded, 
Acknowledged, Modem, Hangup, Callback 
Later, Internal Error 

6) Size 

7) Cost 

D. DeliveryRequest fields (out) 


1) 

Id 

2) 

EstDuration 

3) 

EstSize 

4) 

Status 

5) 

Details 

6) 

Completed 


E. Range (fields:) 

i. Object (i.e., type of object trying to look up) 


i. 

Type 

ii. 

Start 

v. 

End 
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Every transmission to API 145 requires a Request, which will generate 
a Response from API 145 (and the server modules with which it functions) . 
The Request must identify one or more valid "members" by means of 
UserNames. A request contains the following required fields: 

5 Table 2: Request Fields 


iisiiiiiisi 
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(In this and other tables, the In/Out column indicates whether the field 
is used in a Request (in), in a corresponding Response (out), or in both.) 

10 In addition to fields, the Request will generally contain one or more 

Major Objects. Typical actions include: send a message to specified 
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recipients; add/edit/delete member, distribution list, contact information; look 
up the status of a job; send a billing inquiry. The following represents a 
typical Request (with the Contact Object, discussed in greater detail below, 
indicated but not actually specified): 

5 <Request> 

< Us e rName > Ra lphw < / Us e rName > 
<Password>abcl23</Password> 
< Doma in > POETS < / Doma in > 
<OEMId>OEMId< /OEMId> 
1 0 <OEMPassword>OEMPassword</OEMPassword> 
<RequestType>validate</RequestType> 
[Contact Object] 
</Request> 


1 5 The Response is generally returned with the same objects that were 

included in the Request; if, however, the Request asks for information (e.g., 
a request for message status or for billing information), some objects or 
fields may be added or changed. In addition, the Response will contain 
Errors and Warnings fields as appropriate: 




; - :. • i.--..?.u;Zr 

In/Out 
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20 

Table 3: Errors and Warnings (Response Fields) 
Errors and Warnings are described in greater detail below. 
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The following represents a typical Response (with the Contact Object 
once again indicated but not actually specified): 


<Response> 

<UserName>RalphW</UserName> 
<Password>abcl23</Password> 
< Doma in > Poets , Inc . </Domain> 
<OEMId> OEMId</OEMId> 

<OEMPassword> OEMPassword</OEMPassword> 

<ResponseType>validate</ResponseType> 

<Errors>2< /Errors > 

<Warnings > 0< / Warnings > 
[Contact Object] 
< /Response > 

Requests and Responses specify one or more Major Objects as 
follows: 


Major Object 

Description 

Member 

User-level login that identifies a user account (end user or member) 

Contact 

Person or organization to which a message may be sent 

Distribution List 

A group of contact methods (for example, phone number, pager number, email 
address) to which a message may be sent 

Job 

Message to one or more contacts using one or more contact methods 

Range 

Used to look up other objects based on specific search criteria; for example, to 
look up a job by Id, or jobs sent on a certain date, or all contacts from the same 
organization 


Table 4: Major Objects 


Each Major Object contains zero or more fields and sub-objects, which 
may themselves contain additional sub-objects and/or fields. The various 
Major Objects will now be described in detail. 
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Major Objects— Member : generally an end user of the messaging 
service. 

Major Objects— Member— Fields : The Member object has the following 

fields: 


iifiHieiapi! 



In/Out 

Alloyufl 

li/Ijue " 
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Iff 
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IS 
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fl 
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SSIJIIl 
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|| 
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(M 
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^ame 
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i?|l; 

in 

Stfirig 

WltJl^32: 
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limit J v 

4 

illlllppllilll 

IBBKillSBMll 

11 
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•. 

.•r/i;^ 

HI 

mm 

Mm 
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me > i 

list! 

IP 
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* 
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I- 
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String 
witha ? 32-; 

limitl|p|jp 

Press^Cbriipan , :. ' 

plpBililill 
Usert^^|||r ; :: 

The memt^^ be ' 
unique wffimithe domain . ? 


Stfing\l^l^ 
witr|a!^ 
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Urttft||l|g 
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IBilllllllllllP 1 
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String ; : 
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cKaractief 5i 
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AllowNotices^ 

inter^isteci : :ih ^reb^iyiiffi^cei^flMy 
pghodicjniam^ 


allSvv)i; ii 
otnerwise^-i 


|iiM||p|| 

i n is is ? way^ior^ine mem Dcrnio : 

a voicejresi)^ | 
touchfo 

1111! 


<Dia!L inld> 9 1 4 6 44 5 5 4 3 <^Dial xnl d>; 

DialinPassAvor 

Serves'as a PINilG^he^^icel-^l::'- 

?f'< 

Numeric 
string i 

<0rap.ihPassword>3^ 


Table 5: Member Major Object Fields 


Major Objects— Member— Sub-objects : In addition, the Member 
object contains the following required sub-objects: 

5 Major Objects— Member— Sub-objects— Contact Method : specifies 

communication mode (e-mail, telephone, etc.) and contact information (e-mail 
address, telephone number, etc.) specific thereto. Contact Method sub- 
objects are further described below in connection with the Contact Major 
Object. 

10 Major Objects— Member— Sub-obiects— Billing : specifies the billing 

plan and details necessary to bill the member (such as a credit-card number). 
The object also describes the current account status. The following table 
sets for the required fields for the billing sub-object: 


llliiiialll?! 


Out 

Allowed; 

^Yalues;^ 



Uniique;ic!en^fie^ 

Qiitl 
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■i ' i! ::.:^^" i^cV' ? : ; : -V : : .;<■ \ H- iP 

Indicates whicK^ 

usffigfil^^ 
using =a;£re^ 

ill 


#1 


6urrentBalanc& 

Giflrenib^ariceiiriil 



^currentBalance>a5iv 2;2-r^tk: : M'-- r 


floating-point number : > : : M:- h = v 1; fti 'W 

4'^, f ~-: : : 


<c / Current Balanee ; ^ ^ ; ^4tm,Bm^i: 


Table 6 
Member Major Object 
Billing Sub-object 

5 The billing sub-object, in turn, contains a Credit Card sub-object, the 

fields for which are set forth in the following table: 


In/Out 


lilllijjjfi 

MiddleNaMe^^ 

iMtNanSBMSi 


Name> is^it • - ^ 
^e^;^n:the • 


Iril 


Each nam^ifielcl; 
is a s^g^withfa| 

3&li|^c||p||l|^ 



NiBnteppIll; 


In 


Number as it. 
appeare on tli^ 


< Cr edi t Gar dNumbe r ^512 31 23412341233 mmm 
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Month ! ; H 


Expirations 
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T^oSiipif 
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a||ip|^ffil| 
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wmmm 


StreetAddress2l 


Second line of . 
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ddiress forthisi 


In 


Set6hd?lirieSbifSf 
billing address : ;\ 


<St2reet^ddre^s2^ 


J;;M ;: : 


Cit>|of billing ;k 
^dilssifor^His 


Gity name ; 


State of billings 
^diiss for this 
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^|c 


P|s^^le|t|g|| 
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abbreviatidnB^^J 
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<Stat-e>eA<^S.tate>; ; > ; ^i;^|:^ 
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/ 


iffawilll 


lilll 

|itherfi\^;6r h 
nine; digits^ ; 

hyph^|isb:>?^||^r 









Table 7 
Member Major Object 
Billing Sub-object 
5 Credit Card Sub-object 

The following is an example of entire Member Object: 

<Member> 

< Command > c rea t e </ Command > 

< FirstName>Ralph< /Firs tName> 
10 <LastName>Emerson</LastName> 

< Company > Poets R Us </ Company > 

< Us e rName >RWE < /Us e rName > 
<Password>MyPassword</Password> 
<DialinId>12345</DialinId> 

1 5 <DialinPassword>12345</DialinPassword> 

<ContactMethod> 

<Transport>email< /Transport > 
<Qualif ier>none< /Qualifier > 

<EmailAddress>ralph@Poets . com</EmailAddress> 
20 < / Contac tMe thod> 

< Contac tMe thod> 

<Transport>phone< /Transport > 
<Qualif ier>office< /Qualifier > 
2 5 <Ordinal > 0 <0rdinal / Ordinal > 

<PhoneNum>617-123-4567</PhoneNum> 

< / Contac tMe thod> 

<Billing> 

<BillingPlan>kkk33kkkk<BillingPlan> 
30 <CurrentBalance>l . 00<CurrentBalance> 

<CreditCard> 

< Fi r s tName >Ralph< / Fir s tName > 
<MiddleName> Waldo </MiddleName> 
<Las tName >Emerson< /Las tName > 
35 <CreditCardType>Master 
Card< /Credi t CardType > 

<CreditCardNumber>5123123412341233</Cre 
ditCardNumber> 

<ExpirationYear>2001</ExpirationYear> 
40 <ExpirationMonth>8</ExpirationMonth> 
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<StreetAddressl>1313 Mockingbird 
Lane</StreetAddressl> 

<StreetAddress2>Poets R 
Us</StreetAddress2> 
5 <City>Warren</City 

<State>MA</State> 
<Zip>01810</Zip> 
< Count ry >US A< / Count ry 
</CreditCard> 
10 </Billing> 

< /Member > 

Major Objects — Contact : identifies an individual to whom a message 
may be sent. A Contact Object contains one or more Contact Method sub- 
objects (described below), each of which identifies a way to reach the 
1 5 individual. Contact and Contact Method information may or may not be 
stored in a member's Address Book (i.e., the a collection of a member's 
Contacts and their associated Contact Methods stored in database 1 52b). 
Thus, a Contact Major Object may be created to be stored in an Address 
Book, or for one-time use. 


20 Major Objects— Contact— Fields : The Contact object has the following 

fields: 




In/Oiit 

1 A 1 1 owed 1 Vai I u e is i 


Command ; 
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')■- ' - 

update j*^^; 
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required only when the; f 
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the Address :Bp^ 

reuse.)^vK;^. : '0y : mB 

<Cqmmand^ 4 
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Required field that \; • ^ h 
identifies^the member^*® 
whence Gomrriahd fields 

mmmm 

re/wove theContact.: 


:;:; : sj^->i|i;i^:ir;5i^=: 

update! 
remove) :;| 


j Supplied ^ft(^ a c^inlact! 
hks been;create<£ * 





Prefix V'-:|; r ; 

(||||||})pf : ^ 


Indicates tHie contact's K M 

prefOT^title^fMll^ui: # 
example^ 


flillllll 


MidBle^aine 


TOe contact's fifs^ middle 
and jlas| nai^ 
lastn^es^jrepp^ 


jEaci 


String With 




fieldjis 

III! 



character limit 


hi 


Hi 
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<Mrdd^eName >Sfe:>i||i^^se£:ii:h^:Hv^ . , 


(CD^tio^l); ; ^ : 


hidicates|tiie niim^bf th^; 
comjpktMpSr crgiSiizatidrii ^ r 
vyith which thec^tactis;; 


ss i*;Ef J ii^^k sssfe ibrss f sffi^fe 


affiliated' 


nW >V 4" -ix'-**- 1 :?" 


(l^iilal)f'.;"- ;i 


Indicates^a job ^ 


: ^h|^ii§J|mi|^g^l 


Table 8: Contact Major Object Fields 

Use of the Command field ensures that the Contact Object will be 
stored in the Address Book of the member with which it is associated. 
5 When the Contact Object is nested as a sub-object of a Job object (described 
below), the contact information will not be stored in an Address Book. 

The following represents a typical Contact Object (with Contact 
Method objects indicated but not actually specified): 


<Contact> 
1 0 <Pref ix>Mr . </Pref ix> 

<FirstName>William</FirstName> 
<MiddleName>L . </MiddleName> 
< La s tName > S hake spear e < / La s t Name > 
< Company >Globe Theater, I nc .< /Company > 
1 5 <Title>Director</Title> 
[ContactMethod Objects] 
</Contact> 
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Major Objects— Contact— Sub-objects— Contact Method : as 
explained above, this object specifies the manner in which a member may be 
contacted. A Contact Method sub-object may contain some or all of the 
following fields: 


Field 


Description 


M lowed Values! 


Example 


llliiipf 


Identifiesithis 4 


wilr lis i'y/.Mm& 
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■ | Required i|Mse& | 

; 1§|jg| 
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that does h^e a Commands 
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(Required) 
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Ty)3ical phone dumber with 
distance needed)^for example 


< PhpneNum>?.i2 ^1 231, / . \ | 
<FaxNum>2 i2 12 3:4 5 6 8 < / FaxNum> 

• • ^y:^yy.y-y^Wf^ ^bs-^s^^.^^si^s 

<PagerN\iin>8;00-456^ r ^ ;^ 


: 1 


K567<> 


Ac<cess:numben 
for a pager : . 


In 


Used o/i/k >yheri;the p^r p J 

;:^:j;.i;::^<:::::; ? ;:5V f^i; ■ : v ; : 'i ; x;:.>;-^-:;f::-; ; • 

eiiter Jarilidentiiy ihg^ touch tcxne; 
s^ingi(sometim^ 

th^JpbuMJ : |||h:^^ 



109140-4 


32 
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Table 9: Contact Method Sub-object Fields 


To denote a member's primary e-mail address, for example, the 
following syntax is employed: 

5 <Contact Method> 

< transport >email < /transport > 

<qualifier>member< /qualifier > 

< Email Address >ralph@poets . com< /Email Address > 

10 

< /Contact Method> 


The following example illustrates addition of a new contact to an 
Address Book: 


1 5 <Contact> 


< Command >create</ Command > 

< Fir s tName > Albus < / Fi r s tName > 

< La s tName > Dumb ledore</Las tName > 
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< Company >Hogwarts School for Witchcraft and Wi zar dry </ Company > 
<Title>Headmaster</Title> 


<ContactMethod> 

<Transpor t >phone < / Transport > 
5 <Qualif ier>cell</Qualif ier> 

<PhoneNum>978 55512 34</PhoneNum> 
< /Contac tMe thod> 

<Contact;Method> 

<Transpor t >pager < / Transport > 
1 0 <PagerNum>8885551234</PagerNum> 

<AccessCode>103 0#</AccessCode> 
< /Contac tMethod> 

</Contact> 


1 5 Major Objects — Contact— Sub-objects — Contact MethodRef : once a 

^ Contact Method has been created and stored, it may be referred to using a 

£ pointer called a Contact MethodRef. The pointer contains the Contact 

rQ Method's Id, or a combination of fields that will uniquely identify that 

s Contact Method. 

o 

20 A Contact MethodRef sub-object may contain some or all of the 

following fields: 


c p -lie!d||j^ 
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Qualifier 
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iSf [if sil-l 
laiiilpa 


lil 
fill 
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Table 10: Contact MethodRef Sub-object Fields 

Major Objects— Distribution List : a Distribution List is a grouping of 
Contact Methods. It allows a member to send a message to all of the 
5 Contact Methods in that list. A Distribution List object may contain some or 
all of the following fields: 


Field 


Description! 


In/Out 


Allowed Values 


Example 


mdicateSime;desired 


1011SM 


GoiiMMdl 
(Required);; 


....„ s . . ; .,. ^ ,,^.jpi 

Replace (Replace existing Gontact ^ 
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Methods cdritamedmthi*^ Jllllsf 
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mmmmm 
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" XOIl>IK-x. 


ifhique^i&eiatifiSr^ 


Jlil 


tfffieyalue^th^l 
Gommand field 


lisjfll 


lillMllilil 

|idi>3c43ipf<pd 


plj 


fliisii 
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Table 1 1 : Distribution List Major Object Fields 

In addition, the Distribution List object must have a list of Contact 
MethodRef sub-objects (i.e., pointers to already-created Contact Method 
objects). An exemplary Distribution List object is as follows: 

distribution List> 

< Command >append< /Command 
<Name>Gryf f indor</Name> 

<ContactMethodRef > 

<LastName>Potter</LastName> 

<Transport >emai 1< /Transport > 
< / Con t ac tMe thodRef > 

<ContactMethodRef > 

<Id>kkk3btkk</Id> 
< / Con t ac tMe t hodRe f > 

</Distribution List> 

Major Objects— Job : a Job object contains a message to one or more 
Contacts using one or more Contact Methods, and contains sub-objects that 
define the specifics of the messaging task (e.g., the sender, the body of the 
message, recipients, etc.) A Job object also contains at least one Message 
sub-object (described below), and one or more Delivery Request or Contact 
sub-objects. 

A Job object contains only two fields, and these are specified only in a 
Response: 
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sip* ■ BiUS^^j;: 


In /Out 

A" wed Values 



Identified - j 

py|j| 

Si"' ilSS^' ~ ; -ss ' ;f ^?*' , ': i sV ■ 



EstimatMjcost of this? ^ - 

jG^illll^lllliiiil |ll IIIIk -^i I! 


Fld&mg point;^ 



Table 12: Job Major Object Fields 

Major Objects— Job— Sub-objects— Message : the Message sub-object 
specifies the actual message. It includes fields and optional MessageArg 
5 Objects, and allows the requester to specify delivery times. 
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Example) 
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:jwas-}r: 
submitted ^-^^iv? 


Out:- 8 


itiil 

ill 

: ;: ;;-::i;-i<. 


llliiiil 
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11 llll 


IDeliveiyTime lOptioris}^ 


llliil 
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Table 1 3 
Job Major Object 
Message Sub-object Fields 


Major Objects— Job— Sub-objects— Message— MessageArg Sub- 
obiects : a Message object contains one or more MessageArg sub-objects 
that consist of a series of Name/Value tags according to the following 


1 0 syntax: 


<MessageArg> 

<Name>SENDER</Name> 

<Value>Hermione Grainger</Value> 
< /Me s sageArg > 
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The optional MessageArg Name/Value tags are as follows: 



Table 1 4 

5 Job Major Object 

Message Sub-object 
MessageArg Sub-object Tags 


An exemplary Job Object is as follows: 

<Job> 

10 <Message> 
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<Subject>Extra Quidditch Practice< /Subject > 
<Template>generic< /Template > 

<MessageArg> 

< Name > S ENDER < / Name > 
<Value>Oliver Wood</Value> 
< / Me s s age Arg > 

<MessageArg> 

<Name >BODY< /Name > 
< Value ><! [CDATA [ 

I have scheduled an extra Quidditch 
practice session before the match with 
Slytherin. Be there Wednesday at 8:00AM sharp 
]]> 
</Value> 
< /MessageArg> 

<MessageArg> 

< Name > AS K_YE SNO_QUE S T ION< / Name > 
<Value>YES</Value> 

< / Me s s age Arg > 

<MessageArg> 

<Name > < QUESTI ON_TO_AS K< /Name > 
<Value><! [CDATA [ 

Can you make the practice session?] ] > 
< /Value > 
< /Me s s age Arg > 

<MessageArg> 

< Name > EMA I L_ADDR< /Name > 
<Value><! [CDATA [ 

wood@Hogwarts . edu] ] > 
< /Value > 
< /Me s sage Arg > 

</Message> 
<Contact> 

< F i r s t Name >Harry</Firs t Name > 
<LastName>Potter</LastName> 
<ContactMethod> 

<Transport>email< /Transport > 

<EmailAddress>potter@hogwarts . edu< /Email Adddress 
< /ContactMe thod> 

< /Contact > 

< De 1 i ve r yReque s t > 

< Con t ac tMe t hodRe f > 
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<LastName>Weasley</LastName> 
<Transport >email < /Transport > 

</ContactMethodRef > 

< /DeliveryRequest > 

5 </Job> 

Major Objects— Job— Sub-objects— Delivery Request : the Delivery 
Request sub-object allows the requester to specify a recipient for a job, as 
well as to specify delivery options (as fields within the sub-object). The 
Delivery Request Object may contain a Contact MethodRef sub-object (to 
10 refer to a previously created contact method for the recipient) or may instead 
refer to a Contact sub-object of a Job object (for one-time use of that 
Contact/Contact Method). 

An exemplary Delivery Request sub-object is as follows: 

<DeliveryRequest> 

1 5 <ContactMethodRef > 

<LastName>Potter</LastName> 
<Transpor t >emai 1 < /Transport > 
<Qualif ier>home</Qualif ier> 

< /ContactMe thodRef > 

20 </DeliveryRequest> 

The Delivery Request sub-object is also returned by API 1 45 as a 
Response. Furthermore, when an existing Job object is retrieved using a 
Range object lookup (described below), that job's Delivery Requests are also 
returned. 

25 The Delivery Request sub-object may contain the following fields: 
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Table 1 5 
Job Major Object 
Delivery Request Sub-object Fields 


An exemplary Delivery Request Response is as follows: 


<DeliveryRequest> 

< ID>kz tubkkkkx / ID> 
<EstDuration>80</EstDuration> 
10 <Status>Not Sent</Status> 

<DeliveryOpt ions >Standard</DeliveryOpt ions > 
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<Completed>false</Completed> 
<ContactMethod> 


<ID>kit5bkkuk</ID> 
<Transport >phone< /Transport > 
5 <Qualif ier>of f ice</Qualif ier> 

<Unreachable>false</Unreachable> 
<EmailAddress>potter@hogwarts . edu</E 
ma il Address > 

< /ContactMethod> 

1 0 <Contact> 

< ID >kk3 6bkkkk< / ID> 
<Pref ixx/Pref ix> 
<FirstName>Harry</FirstName> 
<MiddleName > < /Middl eName > 
1 5 <LastName>Potter</LastName> 

<Company>Hogwarts School for 
Witchcraft and Wi zar dry </ Company > 
<Title>Student</Title> 
< OneT ime > t rue < / OneT ime > 

20 < /Contact > 

< / De 1 i ve r y Re que s t > 

Major Objects— Job— Sub-obiects — Delivery Request— Delivery Sub- 
obiect : the Delivery sub-object never appears in a Request. It is returned by 
25 API 145 as a sub-object of a Delivery Request object when a Range object 
lookup (see below) is performed on a job. 


The Delivery sub-object may contain the following fields: 



In/Out 

Allowed 
Values 





<Id>kkk22^524</ld> :MM : %<S& 


Outfit: 

Integer 

<Timestamp >2000 : 06 : 05^ . .-L^r-;| : ; 
04 : 15;::22$/Timestamp>p 
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Duration 


Returns: le^^jpftm in seconds, that server 


Out 


<DtirStion^8g<|Dlira 


Delivery:' vF-;:|;|||:i;,:i : _ 

Not Sebt(fiS^ 

Sent (^i^l^liyery has been su^issfiill|:;||| 
|&v^r^ 
Failed (ITie^^l ^empt^ delivery failed;) 
Gancelled (Your Delivery w 


Out! : :f\ 


N^tSentK,: 

Failed:.y^|- 
Cancelled ^ 
Cancel ;/ 
Pending^ ^ 


^tatus^SENT*:^ Status >"• 


llllliiiii||ilit ; ;|iiil 


J.;;; j;gff 



'J^- : : ::':; v 


Delivei7;Addr^S;is?un)^achabIe (Nail lift 
furth^M^mp^ . ~^I||rg 

No Ahsweif (Mother delivery may ber s ^ft|l| 

Busy ■ (andMeidelivery may be attempted;)lp 


Ai|s^rta^ 
messa&e delivere^^^ 

A n s we r in g Mach in e (phone message 
deli>^d r no ftir^er attempts will be made)P 


^^^^ 



Detailsli; 


(No fuither attempts^will be made;) : ; 
Acknowledge 

the-per^n fi|mbWledged by-gressing'l.:^! ; 


Out^;^.f 


ll-6 


further attempts will be made.) 


Hangup (C||ll ; Svaus ; ^^j^|^^^gl^^ss^S||: 
1 could be delivered; may attemp t 
deliveiy.yjg||; ];\ ^:l^ : ;=^y9"' ;:: 
Callback Later (Message recipient elected^ 
later callba^; aiiothier delivery will be y^;|||; 
ffimpted^ 

Internal Error (internal en;or encountered, 
may attempt another delivery.) 


ply: 


^y||yH^ 


yyyy ' ;r - -r ; y 


Size 


Number oiFp^es in a fiax, if^itwas a fax 


Out 


standard 
urgent ih 


<Size>3</Size> J 


Cost 


Actual cost for this delivery in US Dollars . 


Out 


Floating 

point 

value 


y^#fe^y : 


<Cost>18 . 20</Cost> 


Table 1 6 
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Job Major Object 
Delivery Request Sub-object 
Delivery Sub-object Fields 


5 Major Objects— Range : The Range object facilitates retrieval of a list 

of objects based on specified criteria. In particular, the Range object can 
retrieve Distribution List, Job, and Contact objects. The Response to a 
Range object returns the requested objects. 


The Range Major Object may contain the following fields: 
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Table 1 7 
Range Major Object Fields 


5 The Range object is always included in a Request object, with the 

y value of the RequestType set to "lookup." The most common use for the 

nj Range object is to look up a Job object by Id, for example, 

< Range > 

01 10 <Object>job</Object> 

e <Type>Id</Type> 

Q < Start >kkky5btk< /Start > 


15 


< Range > 

Error Handling : Errors fall into three classes: parsing errors, fatal 
errors, and errors/warnings encountered while validating any object or field. 

Parsing errors occur when the input XML tags do not conform to XML 
specifications. Typical examples of malformed XML code include tags that 
20 are not closed and illegal characters; to avoid the latter type of error, free- 
form text should be enclosed within CDATA tags. When parsing errors are 
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encountered, API 145 returns a ParseErrors object, which contains one or 
more sub-objects called ParseError and having the following fields: 


^(ilillilli 



In/O 

lit; 

Hill 

lii 


Iil^Il;iS|Examp 




E* s ^#; ' ■ ! 

Outfl 

IIS 

Strings 

fifi 

■ 

il 

<Er3rorStririg>Expect^irig 

r ^^^^r^§$r : j^^^ : 'fill© 


v -. k'C \ -\\ "1, 
„>"\^; , - r - 

LineNumber 



Inte^||:;|;;;j;s^; 


|l 
11 

SIR 




Table 1 8 
ParseError Sub-object Fields 


An example is as follows: 

<ParseErrors> 

<ParseError> 

<ErrorString>Expecting *a name', found , /ErrorString> 

<LineNumber>9</LineNumber> 
< / ParseError > 
< /ParseErrors > 

A fatal error signifies a significant problem encountered in the course 
of processing a Request. API 145 returns a FatalError object with a single 
field (ErrorString), which indicates the nature of the error. For example, 

<FatalError> 

<ErrorString>User Transaction Server Unavailable . </ErrorString> 
</FatalError> 
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Validation errors and warnings are attached to problematic objects or fields 
as "attributes." The Errors and Warnings fields of a Response object contain 
the following information: 


ilii 


Errors 

W0\ 


Hi 


Unsigneilt:|5Sl 
integeii 


fff3| 


Wammgs: :; ^;ni 


less;; 


GutI; 


Unsigned ;i;;^v , :; p!-: 

integers 

1 ; ; kv:^ ; 


<:Warnd;ngs>l< Wif 


> 


Table 1 9 
Response Super Object 
Errors and Warnings Fields 


For example, if a Request contains an invalid telephone number, a 
10 warning attribute will be attached to the problematic <PhoneNum> field. If 
a Request fails to provide a Billing sub-object when trying to add a Member, 
an error attribute will be attached to the Member object. 

It will therefore be seen that the foregoing represents a full-featured 
messaging system capable of operating in multiple communication modes 
1 5 and interacting with remote applications through a common, extensible 

interface. The terms and expressions employed herein are used as terms of 
description and not of limitation, and there is no intention, in the use of such 
terms and expressions, of excluding any equivalents of the features shown 
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and described or portions thereof, but it is recognized that various 
modifications are possible within the scope of the invention claimed. 

What is claimed is: 
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